Blog

CommandBox 5.2.1 Release

Brad Wood December 17, 2020

Spread the word

Brad Wood

December 17, 2020

Spread the word


Share your thoughts

Today we are announcing the release of CommandBox 5.2.1.  This is a patch release for 5.2.0 that fixes a few small regressions and adds a few features.

Notable Changes

There is now a new "forgebox logout" command you can use for testing or just to remove your API token from the local CLI.

# Logout one user
forgebox logout username

# logout all users
forgebox logout

You can change CommandBox's default tab completion to be an inline list that follows your cursor. This setting requires you to close and re-open the shell to take affect.

config set tabCompleteInline=true

Read more here: 

https://commandbox.ortusbooks.com/config-settings/misc-settings#tabcompleteinline

We've added better debugging information for Server Profiles.  If you add the --verbose flag to your server start, you'll be able to see what profile was detected for your server, and what baked-in rules have been turned on as a result.

|------------------------------
   | √ | Setting Server Profile to [development]
   |   |------------------------------------------------------
   |   | Profile set from "environment" env var
   |   | Block CF Admin disabled
   |   | Block Sensitive Paths enabled
   |   | Block Flash Remoting enabled
   |   | Directory Browsing enabled
   |   |------------------------------------------------------

We've added a new Single Server Mode you can enable in the CLI to make using CommandBox in Docker images easier.

Read more here:

https://commandbox.ortusbooks.com/embedded-server/single-server-mode

Release Notes

Here are the release notes for the 5.2.1 release.

Bug

  • [COMMANDBOX-1231] - Installing via lex endpoint uses incorrect file extension
  • [COMMANDBOX-1232] - Location of predicate file is in a folder that the Docker finalization script deletes
  • [COMMANDBOX-1238] - Command alas for run command doesn't expand properly

New Feature

Improvement

  • [COMMANDBOX-1227] - verbose server start output for profile and security settings
  • [COMMANDBOX-1228] - Extend ${} scopes to apply to any getSetting() call or "env show" command
  • [COMMANDBOX-1229] - Modules aren't unloaded on reload or shutdown
  • [COMMANDBOX-1233] - Add debug output that shows location of commandbox.properties file on start
  • [COMMANDBOX-1234] - Add single server mode for CommandBox in a Docker container
  • [COMMANDBOX-1236] - Add Testbox runner to sensitive paths in production profile
  • [COMMANDBOX-1241] - Use UTF-8 when reading files with "cat" command

Add Your Comment

(1)

Jan 09, 2021 22:51:29 UTC

by Douglas Cohn

Hi Brad, Are there any plans to do this type of image for Azure? I was led to believe if running a lot of Windows VMs Azure is a better choice especially with monthly fee of the Windows Server at Amazon versus Microsoft. I finally have management looking very seriously to using Lucee and the question that comes up is why use CommandBox to run Lucee versus installing Lucee directly on a Server 2019 VM. I was under the impression that Command box is much easier to pick up the whole environment and drop it on another server. I also thought that CommandBox was great at managing the updates and along with the service piece can be used for Production as well. Production is why we have been looking at it. That said what is the advantage of installing CommandBox for a Lucee production server in Windows Server 2019 versus installing Lucee directly on the VM. Recently the dev started looking at the server we had setup for a Commandbox and he said his code broke because Lucee was updated. I had thought I locked the configs to a specific Lucee version. When I looked at the config Lucee was locked but at a major version. The upgrade was .92 to .95 I believe. Lucee 5.3.5 and I assume the minor version update was possible. But break code and lose all his DSNs sure seems odd to me. "app":{ "cfengine":"lucee@5.3.5" Have a great day/night weekend Doug

Recent Entries

12 days of BoxLang - Day 3: SocketBox!

12 days of BoxLang - Day 3: SocketBox!

As BoxLang continues evolving into a modern, high-performance, JVM-based runtime, real-time communication becomes essential for the applications we all want to build: dashboards, collaboration tools, notifications, live feeds, multiplayer features, and more.

That’s where SocketBox steps in — the WebSocket upgrade listener built to work seamlessly with CommandBox and the BoxLang MiniServer. ⚡

Today, for Day 3, we’re highlighting how SocketBox supercharges BoxLang development by giving you fast, flexible, and framework-agnostic WebSocket capabilities.

Maria Jose Herrera
Maria Jose Herrera
December 12, 2025
12 Days of BoxLang - Day 2: CommandBox

12 Days of BoxLang - Day 2: CommandBox

BoxLang + CommandBox: The Enterprise Engine Behind Your Deployments

For Day 2 of our 12 Days of Christmas series, we’re diving into one of the most powerful parts of the BoxLang ecosystem: CommandBox the defacto enterprise servlet deployment platform for BoxLang.

If BoxLang is the language powering your applications, CommandBox is the engine room behind it all. ⚙️

Victor Campos
Victor Campos
December 11, 2025
12 Days of BoxLang - Day 1: ColdBox

12 Days of BoxLang - Day 1: ColdBox

ColdBox + BoxLang: The Future of Modern MVC on the JVM Welcome to Day 1 of the 12 Days of BoxLang

To kick off the series, we’re starting with one of the most powerful combinations in the Ortus ecosystem: ColdBox + BoxLang.

ColdBox has been the standard for modern CFML MVC development for over a decade. BoxLang is the next-generation dynamic language built for JVM and beyond. Together, they reshape how developers build web apps, APIs, microservices, CLIs, and soon desktop applications.

Let’s dive into why ColdBox 8 + BoxLang PRIME is a major milestone for the future of modern application development.

Maria Jose Herrera
Maria Jose Herrera
December 10, 2025